A fruit fly circuit as a batch job

FlyBatch: one fruit fly circuit. The same answer on a laptop, on emulated s390x and on emulated MVS 3.8j.

FlyBatch simulates the sugar-to-feeding circuit of the male fruit fly: a 501-neuron subcircuit taken from the MaleCNS v1.0 connectome, run with the leaky integrate-and-fire model of Shiu et al. (2024) in a portable C89 engine with a COBOL batch driver.

Read the code How it works Reproduce it

Called ONFLY until 2026-09-27. MIT licence.

The 501 neurons of the subcircuit at their soma positions in the fly's nervous system, joined by 10,783 connections; the two MN9 feeding motor neurons are stars and the 14 sugar-sensing neurons triangles.
The shipped subcircuit: 501 neurons and 10,783 connections, drawn from its own network file. It shows wiring, not activity.

FlyBatch has not run on IBM Z hardware. The project does not have IBM Z access yet. Every MVS result here comes from MVS 3.8j running under the Hercules emulator, and every s390x result from Linux running under QEMU, both on one x86-64 laptop. Nothing here has run on z/OS or on IBM CICS Transaction Server.

Nineteen requests, the same fingerprints on every row

A request names a sugar rate, a duration and a random seed; the answer gives what the two MN9 feeding motor neurons do, with a CRC-32 fingerprint of the whole response. All 19 golden requests produce identical fingerprints and response records on x86-64, from a Python reference and three C floating-point builds, and on Linux s390x under QEMU.

On MVS 3.8j under Hercules with the GCCMVS compiler the fingerprints are identical, and the response records are identical byte for byte apart from one text field that MVS stores in EBCDIC. With a second MVS compiler, JCC, all 19 reproduce the same way. The z/OS row is empty.

Identical fingerprints show that the platforms agree with each other, not that any of them is correct.

The determinism matrix: rows 1 to 7 each reproduce all 19 golden fingerprints; row 8, z/OS, is empty.

Watch one request

The same golden request, G-16, through the native, SoftFloat 3e and SoftFloat 2c engines, each printing the fingerprint the specification records for it. Real commands, real output.

A terminal session: a control card, the request built from it, the engine's run manifest, and three engine builds each printing FP=BAF81D91.
Linux x86-64 under WSL, gcc 15.2.0, recorded with asciinema. The same script on Windows with MinGW gcc 6.3.0, recorded with VHS: demo-windows.gif.

How it works

Everything that needs a floating-point constant is computed once on x86-64 and shipped as bit patterns. Every binary64 operation goes through one float layer, in a fixed order, never fused; where the platform has no IEEE floating point, as MVS does not, that layer is Berkeley SoftFloat. The full explanation, with the model's timestep, is in docs/architecture.md.

Data flow: the MaleCNS connectome, a Python preparation pipeline on x86-64, three artifacts, and the platforms that run them.
The engine: a pure core that decodes, simulates and answers; a float layer with three backends; and adapters around it.

On emulated MVS 3.8j

The three-step BUZZ batch job, a COBOL driver, the C engine and a COBOL report, ran end to end on emulated MVS 3.8j with return code 0 and printed the five shipped-network golden fingerprints. Under Hercules 4.9.1 on an Intel Core i7-13650HX laptop, one standard 1000 ms request on the shipped network used 161 s of emulated CPU, inside the project's 10-minute budget; this is an emulator figure from one run and says nothing about IBM Z performance.

The MVS job: control cards, the COBOL driver, the C engine, and the printed report, with the step return codes.
The printed output of JOB 420 for request G-17: the engine's run manifest on MVS38J with SoftFloat 2c, FP=F9C7EE77, and the report of both MN9 neurons.
A job's printed output, captured 2026-09-27 on MVS 3.8j emulated by Hercules.

On the emulated MVS lab, typing a request on a 3270 session under INTERCOMM, a transaction monitor that is not CICS, starts a FlyBatch batch run and then shows its result and golden fingerprint; the screen shows the run it started only when the request differs from the last one run. This part cannot be reproduced from the repository because INTERCOMM's licence keeps its code out.

The 3270 screen's rows for request G-17: FP=F9C7EE77 and both MN9 readouts.

The emulated MVS job streams its spike data to the host while it is still running, and for the five shipped-network golden requests that stream is byte-identical to the x86-64 one once line endings are normalised: watch the stream.

The +0.0 that was not zero

Comparing the full MVS and x86 output streams line by line exposed a GCCMVS code-generation fault that had turned every +0.0 in the MVS kernel into a tiny subnormal, a difference no fingerprint had ever caught. The fault is worked around, and a 26-line reproducer shows its cause in the generated code: at -O1 an eight-byte structure of zeros is copied from a four-byte constant. The story is in the write-up.

What it does not show

  • The science was measured on x86-64 only. There, sugar at 40, 60, 120 and 200 Hz made the MN9 feeding motor neurons fire in all 30 seeds at every rate, and zero sugar produced zero spikes in all 501 neurons.
  • One fitted input term. The 501-neuron subcircuit carries one fitted input term standing in for the neurons it leaves out, and with it stays within 10% of the MN9 rate of the 184,099-neuron annotated MaleCNS network (39.0% of its synapses) at 40, 60, 120 and 200 Hz; 10 Hz is excluded because that network's rate is too variable there to test against.
  • Shape, not magnitude. Compared with Shiu et al.'s model of the female FlyWire connectome, re-run from their published code, the model on MaleCNS rises with sugar in the same shape but fires more at low rates: 3.67 Hz at 10 Hz where the reference is silent, and 14.35 Hz against 4.73 Hz at 40 Hz. No single synaptic weight removes that gap.
  • Two acceptance criteria were changed after we saw the results: ACC-3 no longer tests 10 Hz, and ACC-4 no longer tests magnitude. Both changes and the failing numbers are recorded in the specification.
  • Emulators are emulators. The s390x results come from QEMU's instruction-by-instruction emulation, so they show the code gives the same results on a big-endian system, but say nothing about floating point on real s390x hardware.

Built in the open

FlyBatch is built with an AI coding agent, Anthropic's Claude Code, working from a public requirements specification. The owner makes every decision, and each is recorded with the alternatives offered; every verification limit is recorded beside the result it limits.

The specification FAQ Contributing Send a replication report