SQCM v3.0: a second ruler for mainframe code, and licenses outside the score
A maturity score is only as good as the inputs it was built to read. The default SQCM ruler reads repositories that have package managers, test runners, CI pipelines, and Git history. A COBOL estate has copybooks instead of packages, JCL and CICS definitions instead of an application entry point, few unit tests, and often no Git history at all. Scored with the default ruler, it would receive a number whose inputs mean something else.
SQCM v3.0 adds a second ruler for that case and documents a second kind of evidence: licenses, which inform decisions without entering any score.
A profile is a complete ruler
Version 3.0 introduces scoring profiles. A profile defines its own domains, metrics, bands, weights, composition, and level rules. Every run is scored by exactly one profile and records it in its score version: v2.2 for the default profile, mainframe-v1.0 for the new one.
Profiles share the 0-100 scale and the level bands at 40, 60, 80, and 90, so a portfolio can be read on one axis. The numbers are not interchangeable measurements, though. A mainframe 80 and a default 80 come from different domains and weights, and the evolution reports treat a profile change the way they treat any change of calibration.
What the Mainframe profile reads
No general-purpose analyzer in the engine parses COBOL, JCL, or CICS definitions, so the profile uses its own lexical reader. It finds the programs a job or a CICS transaction starts, follows static calls and transfers, resolves calls through a variable when a program name appears as a constant, and reports what nothing reaches as unreferenced, never as dead code.
Its five domains are Reliability, Modernizability, Maintainability, Security, and Testability, weighted 30, 25, 25, 10, and 10. Reliability asks whether file, CICS, and SQL errors are handled. Modernizability asks whether the sources are complete and whether the entry points are known. Maintainability reads GO TO density, repeated logic, dead paragraphs, and program and paragraph size.
Two locks matter more than the average. A system that uses ALTER, misses more than 5% of its referenced sources, has a security signal, or exposes no entry point stays at level 2 whatever its score. Level 4 and above also require unit tests and continuous measurement.
Calibrated on public code, and corrected by it
The bands were set on nine public repositories, about 107,000 lines of COBOL: vendor demonstrations, a published service, production code published by the French tax administration, a synthetic benchmark, and samples. The paper lists each repository with the revision that was read, and the reading was repeated at those revisions with identical results.
Calibration was first a test of the reader. Every number that did not match the source was checked in the file. That is how the reader learned to read CICS definitions installed by a batch job, to follow performed sections when deciding whether a paragraph is dead, and to leave tool-generated programs out of the maintainability inputs. In one demonstration system, dead paragraphs fell from 59.1% to 9.6% once sections were honored.
The results separate systems for the stated reasons. One demonstration scores 81 and still stays at level 2, because it contains ALTER statements and its CICS definitions name programs whose source is not in the repository. Another has the lowest reliability, 40, because 39% of its CICS data commands and 32% of its SQL statements are not followed by error handling. The corpus is small and mostly demonstration code, and the paper says so: the profile will be reviewed with the first customer estate measured under authorization.
Licenses inform decisions, and stay out of the score
Whether a strong-copyleft or network-copyleft component is acceptable depends on how the software is used and on the organization's policy. A score that moved with license findings would make the same code read differently in two companies, and the instrument would be answering a legal question on their behalf.
So SQCM records license evidence and evaluates it against each organization's own policy, without changing any domain score. The paper describes the inventory of every resolved dependency, built artifacts, copied files, the policy and its exceptions, the check on pull requests, and the exported SPDX document and third-party notices. It also states what the evidence does not establish: it reports declared licenses, it does not determine whether a component is used at run time, and it is not legal advice.
What we verified, and what remains open
The additions were audited on the production revisions of the services that implement them, with 127 passing tests across 15 suites, a dated copied-code test against the free SCANOSS knowledge base, and a format check of an exported SPDX document with the official SPDX tools. These are vendor-run checks. They do not show that a mainframe level predicts migration cost, or that a license inventory is complete.
Read the methodology
The research page has the paper, an English PDF, its Portuguese translation, the version DOI, the validation note, and a CSV with every calibration metric and score. Earlier editions remain available under their own permanent records.
Cite this edition: SQCM v3.0 · DOI 10.5281/zenodo.23106322.