pachot/oracle4 repository overview

⁠Oracle V4.1.4.1 on PDP-11

Play with Oracle V4 through UFI, the User Friendly Interface and an ancestor of SQLPlus. Oracle later followed UFI with AFI, the Advanced Friendly Interface, before introducing SQLPlus.

docker run --rm -it --platform linux/386 pachot/oracle4:latest

This container runs Oracle V4.1.4.1 for the PDP-11 on RSX-11M-PLUS. The production media was generated on 5 March 1985 and recovered from https://www.oracle-v2.online/⁠. SIMH, an open-source historical computer simulator, emulates a PDP-11/70 with 4 MiB of memory. SIMH itself runs in a 32-bit x86 Linux container. On ARM hosts, Docker uses QEMU to execute that linux/386 container, so startup takes longer.

The entrypoint performs the complete startup automatically:

1. Validate the embedded RSX and Oracle disk images.
2. Create writable runtime copies of the bootstrap and RD54 system disks.
3. Boot RSX-11M-PLUS V4.6 BL87 on the emulated PDP-11/70.
4. Mount the Oracle work disk and refresh the Oracle shared-code images.
5. Load the 250,560-byte ORASHR shared region.
6. Install the Oracle tasks and warm-start the database.
7. Connect UFI as SYSTEM/MANAGER.

The startup is finished when the UFI> prompt appears. SQL statements and UFI commands end with a semicolon. Start with the built-in help:

HELP;

You can then query DUAL or run other SQL commands:

SELECT * FROM DUAL;

The expected result is:

D
-
X

You can also list all tables, including the catalog:

SET PAGESIZE 100;
COLUMN TNAME FORMAT A30;
SELECT * FROM TAB;

To preserve changes between runs, add a Docker volume:

docker volume create oracle4-state
docker run --rm -it --platform linux/386 \
  -v oracle4-state:/state \
  pachot/oracle4:latest

oraclev414_01jan2025.dsk is a SIMH PDP-11 disk container downloaded from https://www.oracle-v2.online/⁠. It contains a 10 MiB DEC Files-11 ODS-1 filesystem followed by a 512-byte SIMH metadata footer.

Startup is automatic. SIMH boots the RL02 bootstrap, boots the generated RD54, mounts the Oracle work disk, refreshes ORAROO.TSK and ORAOV*.TSK, loads the shared region, warm-starts Oracle, and connects UFI as SYSTEM/MANAGER. Wait for this prompt:

UFI>

The tested Docker milestones are:

ORL: shared region successfully loaded.
IOR: ORACLE warm started.
Connecting to: Two Process ORACLE V4.1.4.1 - RSX11M+ Production

This is a runtime wrapper around locally prepared disks, not yet a complete from-original-media unattended installer. A reproducible build must also automate the V4.6 BRU restore, SYSGEN answers, Oracle copy/build, and database creation without redistributing either product.

The generated PDP-11/70 executive boots with user I&D-space support, ORL loads the 250,560-byte ORASHR shared region, and IOR initializes the database. The validated banner and query are:

IOR: Two Process ORACLE V4.1.4.1 - RSX11M+ Production
UFI> SELECT * FROM DUAL;

D
-
X

The working layout keeps the built Oracle files and database in DU2:[4,200] on the RD54 system volume. Loading the shared-code images from the separate 20,480-block Oracle work volume failed with RSX IE.IFU even when that volume was attached as DU0. Copying the identical contiguous images to the RD54 resolved it.

After booting the generated image, the essential warm-start sequence is:

RED DU2:=SY:
RED DU2:=LB:
CON ONLINE ALL
MOU DU2:RSX46
SET /NAMED
SET /UIC=[4,200]
ASN DU2:=OR:/GBL
ASN DU2:=OS:/GBL
DFL "DU2:[4,200]"=SYS$ORACLE/GBL
@DU2:[4,200]INSORACLE.CMD
IOR W

IAP.TSK is absent because its link failed during the native build. UFI, IOR, SGI, CCF, and the remaining built utilities are sufficient for the proven database runtime.

SIMH recognizes ODS-1 for disk sizing but does not provide a host-side Files-11 file-copy command. Common ods2 tools target VMS ODS-2/ODS-5 rather than PDP-11 ODS-1. PUTR 2.01's read-only ODS-1 implementation also does not enumerate this image, even when forced to /FILES11, auto-detected, and given the documented UIC plus a wildcard that includes file versions. RsxLst successfully reads the home block, index file, file headers, directory records, retrieval pointers, and RAD50 names, avoiding lossy raw-file carving. RMS record decoding is performed separately so the extracted bytes remain auditable.