Tape systems and the Tape Utility Frame

Public MIT and LM-3 material

The System 46 source tree at the pinned Git commit contains 1,895 files totaling 54,459,607 bytes. The exact search was performed on a clean local copy on 2026-07-18. The one substantive magnetic-tape program found by the broader search was src/moon/rayth.30, 15,843 bytes, SHA-256 55ecb7ec829ef92576595ce78b2fa57411e414294f24ee938352cc88d4c50d91. Its accompanying src/LICENSE is 1,516 bytes, SHA-256 05b8de7c86c946cc747ab71a9aaa7dd56e37365278b5585ab685156eaa90fb92.

The LM-3 checkout was matched through its Fossil database to check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91, tagged system-303, dated 2025-01-06 15:52 UTC. Fossil reported 4,917 checkout records and no changed files. The following files are the principal evidence:

Licensed Genera material

The source paths below are archive-relative identifiers, not repository links. Checksums let another licensed researcher identify the same inputs without publishing them.

Three installed-Help source records supplied documentation that is more complete than the available implementation subset:

The public Genera 8 Site Operations scan used for cross-checking is 2,293,893 bytes, SHA-256 6812c8f6131954751ce8f5ca281a451546d9e61e75b34af106971889a3f384f2. Relevant printed pages are 755–781.

What was restored

The current read-me calls this a back-port of the LMI Lambda “new tape” system to CADR System 100/300 releases. It says the files came through Bogodyne and GigaMos from LMI, and notes that the code was copied from an LMI RELEASE-3.TAPE tree on 1986-10-02. The maintained source expects a release later than System 109 with patch 109.80, except where the CADR port supplies compatibility.

The current system declaration divides the material into three loadable systems:

An older system.lisp additionally declares old Tape/FDUMP/Copy/PDP-10 material, WESPERCO (MTRQB, WEUNIT), TAPEMASTER (TMDEFS, MTRQB, TM, TMUNIT), and VMS-TAPE/VMST. These declarations establish historical source organization, not that each controller is enabled by the maintained CADR configuration. The checkout also contains tapetest-format.lisp, but the current TAPE format module does not name it. Its presence is source history, not a currently loaded format declaration.

Layering

The implementation separates interaction, logical tape format, device, and transport:

TFrame or TAPE user functions
        -> basic-tape-format (LMFL / RAW / TANALYZ / TAR)
        -> basic-tape-device
        -> CADR RTAPE client -> Chaos RTAPE service -> physical drive elsewhere

The format object controls tape headers, file properties, listing, file navigation, restore, compare, append, and finalization. The device object controls locking, status, motion, record transfer, file marks, and optional direct disk operations. This division is why the same frame can expose format and device choices separately, and why a format can reject an operation even when the device can move the medium.

Generic device contract and concrete devices

Every basic-tape-device is expected to implement initialization and deinitialization; lock, unlock, and lock-state testing; option set/reset; status and speed; rewind and unload; forward and reverse spacing; forward and reverse file-mark motion; chunk, block, and array I/O; optional direct disk read/write/compare; and writing a file mark.

The original device syntax accepts Host:DeviceUnit: or DeviceUnit:. The restoration adds Host:Device:Unit. Device selection parses the registered device name, constructs the matching flavor, then applies options. No default physical drive can be inferred from a syntactically valid specification.

The RTAPE read-only option requests a read-only mount, but its write-block, write-array, and write-filemark methods only issue a warning before sending the write opcode. Effective protection therefore depends on the server honoring the mount mode. A preservation harness must enforce read-only state below this client, not treat its warning as a write barrier.

CADR RTAPE protocol

The CADR client opens the Chaos contact name RTAPE. It provides record/block transfer and the following protocol operations:

The restored client fixes the status record's drive-name field at 15 bytes—16 bytes when the separate one-byte name-length field is counted—where some upstream RTAPE code used 16 for the name itself. Direct disk read, write, and compare are explicitly unimplemented and signal errors. Thus RTAPE is a remote record device, not a disk image format or a virtual-machine checkpoint mechanism.

Format capabilities

LMFL's write path distinguishes end-of-tape in a header from end-of-tape in file data, can unload and request the next reel, and carries continuation state. The restoration read-me specifically reports that Version 7 TAR works; that statement must not be generalized to modern ustar, PAX, GNU extensions, or arbitrary link semantics.

TANALYZ contains two definitions of its :previous-file method. The later one replaces the earlier definition and differs only in a small sequencing wrapper. That duplicate is source-visible maintenance evidence, not a documented feature. For RAW, byte size and character mode are open-file arguments rather than persistent format-menu options; the only RAW format-menu option is record size.

TAPETEST is especially dangerous to infer from its friendly format registration. The file carries a 1988 GigaMos copyright, later than the 1986 LMI frame sources. Its three-pass routine rewinds, writes a leading-offset zero pattern, overwrites the medium with one bits, reads and compares, then unloads. It repurposes compare-file so TFrame's Verify path can start the test and signals logical end-of-tape to stop the generic loop. It is for an expendable scratch tape only. The source even contains a duplicate unsupported :write-file method, another sign that this unconfigured file should be treated as restoration material rather than a demonstrated production feature.

Complete user-level operation surface

The public user.lisp exposes the following release-bounded operations. The table groups them by function but does not omit any entry point found in that interface.

An operation's presence in this API does not imply that every format implements it. For example, position-to-append is part of the generic interface while the TAR method is an empty stub and RAW has no corresponding structured-file operation.

test-device is not a safe inspection command. It rewinds and overwrites the selected tape while testing one-block and array transfers. It then offers a confirmed direct-disk test that writes 500 blocks from one half of a selected partition to tape and reads them back over the other half before comparing the two regions. The CADR RTAPE implementation rejects those direct-disk methods, but that is not a safety mechanism for other devices. The helper named fill-string-randomly actually writes a deterministic index-modulo-123 pattern. These are source-only diagnostics for disposable media and partitions.

Entry point, layout, and interaction model

TFrame registers System-B with the label Tape Utility Frame. That is its only application-specific key binding in the inspected source. It can also be selected from the rightmost-button system menu when the system is loaded. The interaction pane inherits the ordinary Lisp top-level input editor, but the frame does not define an editor-like accelerator table of its own.

The title is LMI Tape Utility Frame (V. <tape-system-version>). The frame chooses landscape or portrait constraints and composes seven named panes:

The layout choice is not an aspect-ratio test: source selects the landscape constraint only when the main screen width is exactly 1,024 pixels and selects the portrait constraint for every other width. Resizing reruns that rule.

The interface is menu-first and depends on mouse-button distinctions:

• clicking a mode changes the command and option menus;
• Left on a command invokes its primary action, Middle invokes the secondary action where one exists, and Right asks for that command's documentation;
• Left or Right on an option cycles through or edits values according to its type, while Middle asks for option documentation;
• Left on the selected format/device chooses another item, Middle edits that object's options, and Right restores the frame's default format or device selection; changing the device deinitializes the former device;
• Refresh redraws the whole frame;
• Restart signals the frame restart, rebuilding commands and resetting options; and
• QUIT selects the previously selected window. It does not kill the frame and does not by itself unlock a tape device.

Killing the frame runs an unlock operation on the selected device. The startup code can leave the selected device as NIL when no registered device is detected, yet the kill path calls unlock without first testing that value. This is a source-visible no-device hazard, especially relevant to usim.

Two options are global in every mode: Global numeric argument, default 1, and Global pathname argument, default NIL. Their effect is command-specific.

Control mode

Control is the default startup mode.

Tape Info mode

The “attempt” qualifier on Get File Properties is important: it catches physical beginning-of-tape conditions around the forward and reverse positioning calls, so a successful property return is not a general transactional-position guarantee for an arbitrary device failure.

Dump mode

LMFL can continue onto another reel when End of Tape Action is Continue. The option does not manufacture multi-reel behavior in a format that lacks it.

Backup mode

The backup-log subsystem is what lets Incremental selection reason about prior backups. “Backup Host” is not evidence that a remote file system is supported here; the source fixes this option to the local host because the remote path was not implemented.

Retrieve mode

The transform option is deliberately broad: a pathname can reroot output, and a function can compute destinations. Its existence is not a promise that author, creation date, or every source-host pathname property survives every format.

Backup Logs and Self Documentation modes

Backup Logs shares the local Backup Host option and offers:

Self Documentation has Documentation Format, either Text or BOTEX with Text as the default, and one command:

The formatter walks mode options and commands, making the frame partly self-describing. This is generated documentation from registered definitions, not a record of runtime hardware support.

TFrame source findings absent from the user story

• The command-definition documentation advertises an :EXECUTION-CONSTRAINTS facility and a :TAPE-ALLOCATED constraint, but the command structure and macro expansion contain no corresponding field or enforcement path.
• A macro comment says command strings will gain [R: Document Command]; the code actually appends [R: Document self]. Right still enters the documentation path, but the implementation's displayed phrase differs from its own macro commentary.
• *comment-output* looks up a drawing-pane, which is not among the frame's declared panes. The variable is not the documented interaction pane.
• The saved compiler-warning file records likely undefined tape calls and free variables, including *HOST-TO-USE*. Some warnings can be load/compile-order artifacts, so this is evidence of unresolved build hygiene, not proof that every warned command fails.
• Verify Files is displayed in Dump, Backup, and Retrieve modes and its own documentation promises post-write or post-retrieve verification. In the inspected commands, however, only the two Backup Filesystem branches read *verify-files* and pass it as :compare; Write Files, Write Partition, and Restore Files do not reference the option. The separate Verify Tape command remains available. This is a source/documentation discrepancy, not a verified automatic behavior.
• The restoration read-me still lists “Fix TFrame” as open work.
• QUIT leaves a live frame, whereas killing it attempts to unlock the selected device. These are materially different lifecycle actions.

No maintained System 303 runtime screenshot is published here. The tested public CADR band used elsewhere in this repository is a System 303 environment, but TFrame needs the later LMI tape code loaded and a viable device selection. A reproducible runtime test remains blocked on producing a disposable, hash-identified band with the pinned LMI system loaded plus a controlled RTAPE server. The frame's no-device kill path should be patched or isolated before such a run.

System composition and device boundary

Genera's Tape system declaration combines several layers:

Tape stream API
  -> local cartridge / industry-compatible drive, or remote-tape client
  -> Carry, TAR, TAPEX, distribution, and FEP-tape consumers

The declaration includes remote record streams, a tape-host abstraction, RTAPE client and server, a Unix-side rmt path, Carry, TAR, distribution support, 3600 cartridge and half-inch drivers, and IMACH SCSI/QIC support. FEP-Tape is declared only for 3600 and IMACH machine types. A VLM-specific exclusion in the distribution mapping is another warning that an Open Genera runtime is not equivalent to every supported Symbolics machine.

Several declared physical-driver module bodies are absent from the inspected source subset: the 3600 ldcw, tape-stream, cart-tape, nbs-cart, lstream, and ldebug files, and the IMACH scsi-tape and QIC-100-stream files. The declaration proves system composition; it does not permit a complete controller-level audit. The remote client/server bodies, generic stream layer, Carry, TAR, and TAPEX bodies are present.

The IMACH implementation's local-tape-drives method returns SCSI drives only for MacIvory, Merlin, Zora, and Domino machine families; it otherwise returns NIL. The inspected Open Genera VLM therefore has no source-supported local physical tape drive. A remote namespace entry and reachable RTAPE server would be required for actual media operations. The isolated harness deliberately provides neither.

Contemporary Site Operations documentation distinguishes Cipher and Archive cartridge hardware. A 3600 Cipher drive is limited to about 20 MB, while Archive drives can use a longer tape; the FEP-Tape UI calls the compatibility choice 19 MB versus 39 MB. The source's QIC constants use 8,192-byte blocks, ten header blocks, 138 safety blocks, and a minimum of 4,810 blocks. DC 300 XL/P cartridges for the 3600 family and DC 2000 cartridges for Ivory systems are documented as mutually incompatible physical media.

Tape specifications

A tape specification selects the host, device, unit, and physical parameters. The manual examples are:

Commas, colons, and equals signs can be included in values by quoting them. At a tape-spec prompt, Control-Meta-Y yanks the default specification.

The parser recognizes more parameter spellings than the manual's short table:

The manual's use of “Unit” as a synonym for Device and the source's separate legacy unit argument are release-compatibility details, not evidence for two independent physical selectors in every call.

TAPE:MAKE-STREAM

TAPE:MAKE-STREAM is the central programmatic entry point. Its source-visible surface is broader than the installed Help record:

Installed Help documents host, unit, reel, direction, input-stream-mode, a default 4,096-byte record, density 1,600, pad 0, minimum length 64/Full/NIL, granularity, prompting, No-BOT, No-Rewind, and lock reason. The source additionally exposes several buffering and compatibility arguments. Their source presence establishes an entry surface, not that all combinations are meaningful on every device.

Minimum Record Length can be an integer below Record Length, Full, or NIL; when it is omitted, 64 is assumed. Granularity can be an integer or NIL, and the documented Genera applications use four-byte granularity. Supplying Pad Character without an explicit minimum or granularity requests Full padding for compatibility. Input Stream Mode defaults to T, which hides record boundaries and reports EOF only at file marks; NIL exposes each record end as EOF, after which Discard Current Record moves on. No-BOT-Prompt suppresses ready/BOT checks, while No-Rewind suppresses the normal rewind at close. Cartridge devices ignore the industry-tape record-size, density, padding, and granularity controls where documented.

Stream messages

In addition to ordinary stream I/O, the implementation documents tape-specific messages:

Reverse file skipping is not supported on cartridge drives. record-status and write-error-status expose record-level conditions; they are not filesystem file status calls.

Genera RTAPE

Genera supports both RTAPE client and server roles and discovers a server through a namespace Tape service. The protocol is close to, but not identical with, the CADR back-port:

Responses 33–36 cover login response, data, EOF, and status. The cartridge-size operation is a concrete protocol difference from the CADR client. The presence of Unix rmt and server source does not establish that either service is configured in the inspected world.

Unix rmt path

The UX subsystem also registers a distinct :unix-rexec tape byte-stream protocol on TCP port 512. It invokes /usr/sbin/rmt on recognized DEC AXP hosts and /etc/rmt elsewhere. This is not RTAPE: it speaks the traditional Unix remote-tape command stream and derives a Unix device pathname from host type, density, unit, and No-Rewind state.

The status decoder recognizes these historical device-type codes: 01 TS-11; 02 TU77-family; 03 TM-11; 04 TU78; 05 Unibus GCR; 06 Multibus CPC; 07 Multibus Archive; 08 SCSI Archive; 09 Xylogics 472; 0A SCSI Sysgen; 0B SCSI Emulex MT02; 0C generic SCSI CCS; 10 Sysgen QIC-11; 11 Sysgen QIC-11/24; 12 default SCSI CCS; 13 SCSI Adaptec; 14 SCSI Emulex MT02; 15 Archive QIC-150; 16 Wangtek QIC-150; 17 ADSI; 18–1F generic SCSI CCS; 20 CDC; 21 Fujitsu; 22 Kennedy; 23 HP; 24–27 generic SCSI CCS; 28 Exabyte; and 29–2F generic SCSI CCS. These are remote Unix status codes, not a list of locally attached Open Genera VLM devices.

The stream explicitly reports that it cannot reverse-skip. No rmt connection was attempted: the museum harness has no external route, and legacy rexec requires a separate security and containment plan before any future synthetic test.

Tape Administration command area

The Command Processor command Help Commands :Format Detailed :Command Table Tape Administration succeeded in the live 8.5 world and displayed exactly these 15 commands, in alphabetical order:

1. Compare TAR File
2. Compare TAR Tape
3. Distribute Systems
4. Read Carry Tape
5. Read TAR File
6. Read TAR Tape
7. Restore Distribution
8. Show Carry Tape
9. Show Distribution Directory
10. Show TAR File
11. Show TAR Tape
12. Verify Distribution
13. Write Carry Tape
14. Write TAR File
15. Write TAR Tape

This is a command-table area, not a TFrame equivalent. Commands can be typed to a Dynamic Lisp Listener or invoked wherever the Command Processor exposes that table. The inspected source and Help define command argument presentations, but no dedicated Tape Administration keyboard accelerator map was found. Ordinary Command Processor completion, editing, Help, and presentation gestures remain inherited facilities. Where the Command Processor supplies its common output controls, More Processing is Default, Yes, or No and Output Destination is Buffer, File, Kill Ring, None, Printer, Stream, or Window; these are generic wrappers rather than tape-format options.

Carry-Tape

Carry-Tape is a system-independent file-transfer format within the supported Symbolics family, intended for selected files rather than filesystem restoration or layered system distribution. The source writes a textual version-1 prologue and property lists into 8,192-byte tape records. File bodies use embedded lengths, a minimum transfer unit of 256 bytes, and granularity 4. Character data uses the Lisp Machine character interchange; wider binary data is narrowed only according to the format's explicit byte-size logic.

The command wrapper also inherits the Command Processor's standard More Processing and Output Destination controls where documented. Programmatic entry points are tape:carry-dump, tape:carry-load, and tape:carry-list, with device, tape host, density, reel, and report-stream controls. The programmatic carry-load default for If Exists is Error, whereas the Read Carry Tape command wrapper explicitly defaults it to Skip. Code calling the function and an operator entering the command therefore do not have the same collision default.

The manual says Carry does not span multiple tapes, and the source begins with “multiple tape handling” in its unfinished-work list. A write loop does catch end-of-tape and asks for continuation, but its n-tapes counter remains initialized to one in the inspected path. That combination is evidence of incomplete or untested continuation code, not grounds to override the supported single-tape limit.

Carry groups files according to each original wildcard/filespec request and can use those groups during restore queries. The loader copies file content and computes target names; its documented command does not promise to restore author and creation date properties. “Verify” means reading content back against source/target data, not cryptographic signing of the medium.

TAR tapes and TAR files

Genera can operate either on a physical tape stream or on a TAR byte stream in a host file. The user-facing command surface is:

The implementation is an old Version 7-style TAR, not a modern general archive engine. It uses 512-byte headers grouped into 20-block records and a 100-character pathname field. It does not emit a ustar prefix, PAX records, GNU long names, or the metadata range expected from contemporary TAR implementations. On writing it uses mode 0644 and numeric user/group IDs zero, skips directories and links instead of encoding them, and writes regular-file content. On reading it ignores hard-link and symbolic-link entries. Preservation work should therefore retain the original TAR bytes and use an external modern parser before asking Genera to rewrite them.

Heuristicate tries to choose text versus binary from the source file. A source comment says the inference only works for LMFS because an NFS server reports misleading information. That caveat is not apparent from the command's menu value. The lower-level compare functions default to verbose reporting, while both Compare TAR command wrappers default Verbose to No.

TAPEX compatibility

TAPE:TAPEX is a listener function rather than a Command Processor command. It asks Read, Write, or List?, with single-key choices R, W, and L. Its format is intentionally narrow:

• 1,600 bpi;
• every physical record is 4,096 bytes;
• a logical file is a pathname header record followed by data records;
• octal 200 terminates the header and data body;
• file marks separate logical files and a double file mark ends the tape; and
• data is non-Lisp-Machine ASCII with CR/LF line endings, tabs and form feeds translated explicitly.

The source says it cannot represent non-ASCII extended characters and provides no binary-file encoding. The reader asks for each target pathname and permits skipping; the writer repeatedly prompts for source files; the lister prints header pathnames. The same file contains a separate legacy READ-LMI-TAPE path. These are compatibility tools, not the Carry or TAR formats and not a safe general-purpose archival representation.

Distribution media

Distribution tapes package systems and logical-pathname-based software components, not arbitrary file trees or bootable world images. The complete source-visible Distribute Systems option surface is:

The public manual also shows standard Command Processor More Processing and Output Destination controls. It reports some “mentioned defaults” that differ from the actual default, so the table above follows the inspected command definition rather than prose that describes what another command invocation might prefill.

System Branch and Flatten Files appear only when the Version Control feature is present. The remaining administration commands have these release-bounded controls:

Site Operations says a multi-tape distribution is a set of independently restorable single tapes whose order the operator must enforce. Its summary table says distribution tape is not verifiable, while the live 8.5 command table contains Verify Distribution. The inspected implementation resolves the contradiction for Genera 7-style distributions: it reads the directory, locates each corresponding filesystem file, decodes recorded attributes, decompresses content when required, and compares file and distribution streams, including length/EOF mismatches and a 16-to-8-bit path. Missing files and mismatches enter continuable error paths. It does not compare file properties—the source leaves that as an open question—and it says verification of pre-Genera-7 distribution tapes is not implemented.

Restoration has a separate machine boundary. A recognized Release 6 distribution is handed to the old distribution loader on 3600 builds and on non-VLM IMACH builds, but the VLM branch reports that Release 6 media cannot be reloaded in Open Genera. This is a source-enforced Open Genera limitation, not a general statement about every Symbolics machine.

FEP-Tape Activity

FEP-Tape is for cartridge sets containing world-load and, on 3600-family machines, microcode files. It is not the FEP's Initial File System tape operation: restoring an IFS tape can recreate the disk's front-end structure and destroy existing disk data.

Installed Help and Site Operations describe Select Activity FEP-Tape as opening a frame with a command menu, file-display pane, and listener prompt FEP-Tape Command:. Commands can be typed at that prompt or clicked in the command pane. The file pane uses the standard Scroll, Meta-Scroll, Meta-<, and Meta-> navigation gestures; no FEP-Tape-specific accelerator table is documented in the available material. The declared commands are:

One manual paragraph calls the second command “Add Files for Microcode Version” while the command table calls it Add Microcode Files. The latter is the stable menu label in the installed Help inventory; the former is preserved as a prose variant rather than silently normalized.

The default short tape holds no more than 19 MB for Cipher compatibility. Full Length selects about 39 MB for Archive hardware and must not be used if a reader has only a Cipher drive. A set can span multiple cartridges. Lisp can use a remote tape drive, but FEP-level reading requires a local drive. The FEP cannot create target files; suitable FEP files must already exist before an in-FEP restore. Writing a set from files on a remote FEP filesystem can bake that remote host name into the FEP pathname and make the tape site-specific, so the manual recommends local source FEP files even when the actual drive is remote.

The system declaration names a fep-tape source module, but that module is absent from the licensed source subset inspected here. Installed Help is therefore the principal detailed evidence for its UI. The runtime world did not recognize the documented activity, as discussed below; none of these operations was invoked.

What was exercised

The Genera Xvfb harness session was named d19-tape-20260718, generation 1. It booted the licensed 8.5 world at 2026-07-18 06:45:42 EDT and selected the window Genera on DIS-LOCAL-HOST, XID 4194310, 1,200×900 at (72,55). The meaningful input sequence was:

1. enter Help Commands;
2. enter detailed Help requests for the Tape Administration command table;
3. correct the argument ordering and enter Help Commands :Format Detailed :Command Table Tape Administration, producing the 15-item inventory above;
4. enter Select Activity FEP-Tape, which reported that FEP-Tape was not an activity name;
5. clear the abort state and enter Start System FEP-Tape, which reported that Start System was not a command name.

The last failure does not prove that no Lisp-level system-loading function could load an FEP-Tape module. It proves only that this attempted Command Processor route was absent. The experiment stopped there rather than guessing a loader name or altering the licensed world. It performed no mount, initialization, rewind, erase, read, write, compare, distribution restore, remote connection, or device probe.

Reproducible run record

The VLM ran in separate user, mount, network, PID, IPC, and hostname namespaces. It had no default route, external route, or host file service; the private runtime was the only writable host-backed tree; the exact X socket was read-only; MIT-SHM was disabled and live-verified absent. The runtime reported the required exact X-protocol substitutions and one-shot time reply rather than arbitrary stream interposition.

Shutdown confirmation was accepted and cleanup progress was observed, but the known VLM cleanup stall required bounded SIGKILL. The launcher returned 137; forced_after_confirmed_shutdown_stall, forced_stop, and state_may_be_incomplete are true, while orderly_vlm_host_shutdown is false. The base and private world hashes remained unchanged. The harness did not invoke Save World or create a host process checkpoint; save_world_performed and guest_checkpoint_created remain unknown because the harness cannot prove guest state from intent alone. The session left no resumable host checkpoint and discarded unsaved Lisp state.

Why no screenshot is published

Three raw 1,200×900 captures remain in the ignored session, identified here only for research reproducibility:

None is published. The first is essentially a full licensed Help listing; the factual command inventory above establishes the same research point with less copyrighted screen content. The other two show listener errors, not the FEP-Tape application's visible behavior. They therefore fail the repository's minimum-necessary-evidence criterion for this article even though a limited runtime screenshot can in principle be published on a documented fair-use basis.

Screenshot TODO: reach FEP-Tape or another genuinely visible tape frame in a fresh, hash-identified world without operating media; capture only the empty initial frame and a non-destructive menu state; then perform an image-specific four-factor review under the screenshot publication policy. For public LM-3 TFrame, first prepare a disposable System 303 band with the pinned source and a controlled no-data RTAPE endpoint. Until then, the absent screenshot is an explicit runtime blocker, not a gap filled from the manual illustration.