system on run_unit, submit, start or open_terminal. The call starts from the state the system’s last call left, and the state it leaves becomes the system’s next. Needs harwell:runs:write and harwell:systems:write.
1. Start a system
The first call that names a system starts it on a fresh volume, with the site’s data sets and tables from the codebase’sharwell.toml.
-, starting with a letter or digit.
The result names the system and where its state now stands:
head is the run the system’s next call starts from. It is also a work_id.
2. Keep working on it
LOADJOB wrote, and EODJOB reads what the transaction wrote. Data persists from call to call. The CICS region starts cold on every call, and programs come from repo at ref each time, so an edit shows on the next call.
A failed run’s state becomes the system’s state too, as a failed job’s writes stay on a mainframe.
3. Read it
sql, list_datasets and read_dataset take system in place of work_id and read its current state:
systems lists your organization’s systems, or describes one: its head, when it last moved, its size, the last calls that moved it, its checkpoints, the terminal holding it, and what is running on it now.
4. Checkpoint and restore
restore moves the system back to the checkpoint. Nothing is lost: the state it moved from stays in the system’s lineage. Using a label again moves it to the current state.
5. Delete it
One writer at a time
A call on a system is refused while another call runs on it, naming what holds it:systems shows the same under busy.
A person at a terminal
open_terminal with system gives a person a live system: every transaction the codebase installs, on the system’s data. While the terminal is open it holds the system:
Without a system
To carry state without a name, setreturn_work on a run and pass the work_id it returns to the next call. See Query Db2 and data sets.