mainframe computer
Enable an AI agent to recognise a mainframe computer, assess its capacity and operational condition, and determine which workload, configuration and maintenance actions are supported and authorised.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex + Grok
Purpose and description
Enable an AI agent to recognise a mainframe computer, assess its capacity and operational condition, and determine which workload, configuration and maintenance actions are supported and authorised.
A mainframe computer is a class of high-capacity, highly reliable shared computing system, typically housed in a data centre, that runs many concurrent workloads for a large organisation under centralised operations, security, and availability controls.
It can be Identify the machine and reconcile its observed configuration with authoritative hardware and service records.; Assess whether a proposed workload fits a supported partition, processor role, memory allocation and I/O configuration.; Prepare or perform authorised resource allocation changes within documented limits and dependency constraints.; Trace the partition and device impact of an I/O path change or component fault.; Determine whether a proposed maintenance action can preserve required service or needs a planned interruption.; Collect operational evidence and escalate faults or capacity constraints to the responsible service authority..
Distinguishing features
Establish mainframe identity from the manufacturer's documented product classification and architectural lineage; cabinet size, price or age alone does not establish it.
Distinguish the physical mainframe from a hosted partition or virtual machine by identifying the hardware service boundary and the authority controlling allocation of physical resources.
Distinguish a physical mainframe from an emulator by establishing whether the identified machine implements the mainframe architecture directly or reproduces it through software on another host.
Distinguish it from a supercomputer or server cluster by checking whether the referent is one documented mainframe system rather than an aggregate of independently managed compute nodes.
Scope
+ Physical system identity, architectural lineage and installed configuration
+ Processor, memory and specialised processing resources available to workloads
+ Hardware-supported partitions and their resource and isolation boundaries
+ Channel and I/O configuration at the mainframe boundary
+ Availability mechanisms, degraded states and maintenance constraints
+ Supported and authorised configuration, workload placement and service actions
- Application business logic, transaction semantics and application-owned data
- Operating-system internals and middleware configuration beyond their compatibility and resource requirements
- External storage systems, network fabrics and peripherals as independently managed assets
- Data-centre power, cooling and physical security infrastructure
- Multi-machine clusters, disaster-recovery services and enterprise continuity plans
- Commercial agreements and organisational access policies as independently governed records
Characteristics
- Manufacturer, machine type and serial identity
- Manufacturer identifiers, product family, machine type, model and serial number Establishes which physical system is being assessed and which configuration and service documentation applies.
- Execution architecture and supported software environments
- Documented architecture, architecture mode and supported operating-system and firmware combinations Constrains which workloads can execute and which compatibility assumptions are justified.
- Processing resource configuration
- Processor counts by documented role, separately recording installed, enabled and allocated quantities Prevents installed hardware from being mistaken for capacity that a workload may actually use.
- Usable and allocated memory
- GiB or TiB, separating installed, usable, reserved and partition-allocated memory Reveals resource limits and whether proposed allocations are feasible.
- Partition and resource-sharing topology
- Links between the physical system, partitions, processor pools and dedicated or shared resources Identifies isolation boundaries and the workloads potentially affected by resource changes.
- Workload-relative processing headroom
- Utilisation and queueing by resource class, with observation interval, workload context and metric definition Supports placement and capacity decisions without assuming that a single rating predicts all workload performance.
- Configured I/O reachability
- Links from partitions through documented channel or adapter paths to reachable external endpoints Determines whether workloads can access required devices and which paths a change could interrupt.
- Operational and redundancy condition
- Running, starting, stopped, degraded, under maintenance or unknown; accompanied by component and redundancy evidence Separates current service availability from the ability to tolerate another failure.
- Configuration and service authority
- Links to authorised management interfaces, responsible operators and applicable change permissions Distinguishes technically possible actions from actions the agent may perform.
Also called
+28
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 28 questions.
Mainframe identity and boundary Establishes which physical mainframe is represented and which architectural and service boundaries apply.
Mainframes can be confused with their partitions, emulated environments or multi-machine installations, leading to incorrect capability and impact assessments.
Product and architecture
Records the evidence supporting mainframe classification and execution compatibility.
Documented mainframe identity
Record product identifiers and architectural evidence without using physical size or presumed enterprise importance as classification criteria.
- Which manufacturer, machine type, model and serial number identify this system, and which record establishes its mainframe classification? provenance
- Which execution architecture and modes does this configuration support, and is execution native or emulated? definition
Physical system boundary
Separates the mainframe asset from partitions, attached equipment and cooperating machines.
Service and asset boundary
Record which frames and components constitute this system under its documented identity and maintenance boundary.
- Which frames and installed components belong to this machine, and which are independently identified attached assets? boundary
- Which apparent systems are hosted partitions or guests, and which are separate physical machines participating in a wider service? boundary
Processing capacity and eligibility Records the processing and memory resources that workloads can actually consume.
Installed resources, enabled capacity, processor roles and workload eligibility may differ, so a simple processor count cannot support placement decisions.
Installed and enabled resources
Distinguishes physical resource inventory from currently usable capacity.
Resource availability by role
Record processor roles and memory quantities with their activation, reservation and allocation constraints.
- How many processors of each documented role are installed, enabled, reserved and allocated, and how much memory is usable? measurement
- Which activation conditions or processor-role restrictions limit the workloads that may consume those resources? boundary
Workload-relative headroom
Evaluates capacity in the context of a specified workload and observation period.
Placement capacity evidence
Record evidence of available capacity and contention using metrics whose scope and limitations are explicit.
- What processor utilisation, dispatch delay, memory pressure and I/O waiting were observed for the relevant workloads and time window? measurement
- What evidence supports admitting or expanding the proposed workload within its required service level? action
Partitioning and execution control Describes execution environments, hardware resource assignments and control over their boundaries.
A mainframe's physical capacity and its partition-level availability are different decision contexts, with changes potentially affecting several hosted environments.
Partition topology and isolation
Identifies the supported partitioning arrangement and its shared dependencies.
Execution boundaries and sharing
Record partitions and nested virtual environments, distinguishing dedicated resources from shared resources and control functions.
- Which hardware partitions and nested virtual environments exist, and how are processor, memory and I/O resources assigned to them? definition
- Which isolation guarantees and shared dependencies are documented for this configuration? boundary
Execution compatibility and change
Connects workload requirements to supported environments and permitted allocation changes.
Supported partition actions
Record compatibility requirements and the conditions under which partition resources or execution state may change.
- Which authoritative compatibility records establish the supported operating-system, firmware and processor-role combinations for each target environment? provenance
- Which allocation or partition-state changes are supported and authorised, and which require workload quiescence or a restart? action
Channel and I/O access Records how mainframe execution environments reach external devices through configured I/O resources.
A workload can have sufficient compute capacity yet remain unable to operate because its device definitions, path assignments or accessible I/O resources are unsuitable.
Device and path configuration
Maps configured I/O access from partitions to external endpoint boundaries.
Partition device reachability
Record applicable channel, adapter and device identifiers and reconcile configured access with observed availability.
- Through which configured channels or adapters can each relevant partition reach its required storage, network and peripheral endpoints? definition
- Which configuration records and observations establish that the required device paths are currently available? provenance
I/O resilience and reconfiguration
Assesses path dependencies, bottlenecks and the effects of changing device access.
I/O change impact
Record whether alternate paths provide effective continuity and which workloads depend on a path targeted for change.
- Which paths share adapters or external dependencies, and what observed load or fault evidence limits their ability to carry redirected traffic? measurement
- Which partitions and device accesses would be affected by disabling or reconfiguring a path, and what preparation and recovery steps are required? action
Availability and service actions Connects machine health and redundancy evidence to supported recovery and maintenance actions.
Continued operation can conceal reduced fault tolerance, while maintenance permissibility depends on the actual configuration, fault state and service procedure.
Health and fault tolerance
Separates current execution state from remaining resilience to component failures.
Degraded operation and exposure
Record active faults, isolated components and the redundancy remaining for affected system functions.
- Which service events, diagnostic results and management observations establish the current machine and component states? provenance
- Which redundancy mechanisms remain available, and which additional component failures could interrupt affected partitions? boundary
Maintenance authority and recovery
Defines the prerequisites, authority and verification needed for machine-level interventions.
Permitted service transition
Record supported procedures for the exact configuration, including interruption scope, recovery prerequisites and completion evidence.
- For the proposed repair, firmware change or system restart, which documented procedure applies and which workloads require interruption or relocation? action
- Who may authorise and execute the action, and what recovery preparation and post-action checks must be satisfied? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- IBM Z / System z family (z/OS, z/VM, Linux on Z)
- IBM z/TPF transaction systems
- Unisys ClearPath (Dorado / Libra, MCP / OS 2200)
- Fujitsu GS21 / BS2000 mainframes
- Bull / Atos GCOS mainframes
- Hitachi VOS3 / AP series mainframes
- Legacy plug-compatible mainframes (Amdahl, Hitachi, Comparex era)
- Specialised high-volume transaction mainframes (e.g. airline TPF-class)
- Which of these kinds and varieties hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Identifiers and schemes
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Wikidata - Q177825 - item 'mainframe computer'
- IBM machine type - four-digit type + model, e.g. 3931 / 3932 (IBM z16); 9175 (IBM z17) - product identity on contemporary IBM Z
- ISO/IEC 2382 - term 'mainframe' - IT vocabulary; not a taxonomic code
- Which of these identifiers and schemes hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Standards and regulation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- IBM z/Architecture Principles of Operation (SA22-7832) - IBM
- FIPS 140-3 cryptographic module validation for mainframe crypto - NIST
- PCI DSS - PCI SSC (card-processing workloads commonly hosted on mainframes)
- SOX / equivalent financial-reporting controls where mainframes hold books of record - national legislatures / regulators
- Common Criteria / national schemes for evaluated mainframe security functions - CCRA members
- Which of these standards and regulation hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Real-world use
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Core banking ledgers, payments clearing, and ATM authorisation at large banks
- Airline reservation and departure-control systems (TPF / z/TPF class)
- Government tax, social-security, and census back-ends
- Large-batch overnight processing (payroll, billing, settlement)
- Enterprise resource systems that still run COBOL / CICS / IMS / Db2 on z/OS
- Logical partitioning so one box hosts production, test, and Linux guests concurrently
- Which of these real-world use hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Typical measurements
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Processor capacity - hundreds to tens of thousands of MIPS on a single CPC; IBM publishes MSU ratings per model - MIPS or MSU
- I/O bandwidth / channel count - hundreds of FICON / OSA channels; TB/s class aggregate on current IBM Z - GB/s or channels
- Configured memory - tens of GB on older frames to 40 TB class on current IBM Z max configs - GB or TB
- Availability / unplanned outage - design target often 99.999% for the CPC; planned concurrent maintenance is the norm - percent uptime or hours/year
- Concurrent users / transactions - thousands to tens of thousands of concurrent interactive users; millions of transactions per day on large sites - transactions/s or users
- Power draw of a populated frame - roughly 5-30 kW depending on model, I/O drawers, and cooling - kW
- Which of these typical measurements hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Failure modes and hazards
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Single-site disaster (fire, flood, power) if GDPS / equivalent multi-site is not in place
- Capacity or licensing exhaustion (MSU / software cost) causing throttling or failed batch windows
- Coupling-facility or sysplex timer issues taking down a Parallel Sysplex
- Misconfigured RACF / ACF2 / Top Secret exposing privileged access to books of record
- COBOL / assembler skills attrition and unmaintainable decades-old applications
- I/O or DASD subsystem failure cascading through shared storage
- Unauthorized use of production data in test LPARs
- Cryptographic key compromise on onboard crypto (HSM / ICSF)
- Which of these failure modes and hazards hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Regional variation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- North America and much of Western Europe: 'mainframe' almost always means IBM Z / z/OS in commercial speech
- Japan: Hitachi and Fujitsu mainframe lines remained commercially important longer; IBM also strong
- France and some public-sector Europe: Bull / Atos GCOS heritage still named separately from IBM
- German-speaking public sector: Fujitsu BS2000/OSD historically common in government
- India / offshoring: operations and COBOL maintenance often delivered remotely against on-shore mainframes
- Which of these regional variation hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- supercomputer / HPC cluster - optimised for floating-point scientific throughput and tightly coupled parallel jobs; a mainframe is optimised for mixed commercial I/O, RAS, and shared multi-tenant OLTP/batch
- midrange / IBM Power / IBM i (AS/400 lineage) - smaller shared-system class; not IBM Z architecture, typically one organisation's ERP rather than a CPC hosting many LPARs and a sysplex
- commodity x86/Linux server farm or cloud VM estate - scale-out of many small machines vs one or a few CPCs with hardware partitioning, specialised I/O, and decades-compatible instruction set
- minicomputer (historical) - 1960s-80s departmental machines (PDP, VAX); a mainframe was the larger, centrally operated class even in that era
- high-end UNIX SMP (historical Sun/IBM pSeries) - big RISC boxes ran commercial Unix; they lacked z/Architecture, FICON I/O, and the z/OS software stack
- Which of these neighbouring kinds and how to tell them apart hold for the sense of mainframe computer this model covers, and on what evidence? provenance
Sources
- What is a Mainframe? - Vendor definition, typical workloads, reliability/availability framing, IBM Z as the dominant contemporary family.
- Mainframe Computers - Industry-analyst definition emphasising large-scale transaction and batch processing.
- mainframe - US government glossary definition used in security and procurement contexts.
- ISO/IEC 2382 Information technology - Vocabulary - Standardised IT vocabulary that historically defined mainframe as a large-capacity computer.
What the second pass must settle
- Which vendor and historical product families must this registry entry cover, and what authoritative classification resolves borderline systems?
- How should the model represent a physical system whose documented asset or service boundary spans multiple frames or tightly coupled processing units?
- Which partitioning, specialised processing, capacity activation and concurrent maintenance capabilities are common enough to model directly, and which need family-specific extensions?
- Which performance measures support useful cross-generation comparisons, and what workload-specific evidence is required to avoid misleading capacity equivalence?
- Where should detailed firmware configuration and I/O configuration artifacts be owned so this model can reference them without duplicating neighbouring software and infrastructure models?