Delivery System

The Delivery System, as it was called by Prodigy, initially consisted of:

• The Dialup Access Concentrators and Regional Object Caches, operating initially on IBM Series/1 Minicomputers.
• The Central switch, operating on an IBM Mainframe running TPF (routing functions and fast transactions)
• The High Function Host, another IBM Mainframe running CICS (more complex transactions)

The Prodigy Reloaded Delivery System combines the function of these components into a single application (found in apps/server) and utilizes the Postgres database (supported by an associated component found in apps/core).

Utilities to manipulate databse objects (podbutil, the Prodigy Object Database Utility, found in apps/podbutil) and household / user accounts (pomsutil, the Prodigy Operational Management System Utility, found in apps/pomsutil) are provided.

An additional portal application that will furnish a web-based interface to acquire an account and to otherwise perform the functions provided in podbutil and pomsutil will be forthcoming (to be placed in apps/portal).

The Reception System was the client of the services provided by the Delivery System, and the content that comprised the service was created by the Producer System.

Start the service

docker compose up

This command will:

• Build the delivery system Docker image
• Start the database
• Execute the database migrations
• Clone the git objects repository and add them to the database
• Create a user AAAA11A with an initial password SECRET
• Run the server.

Download dosbox-staging

Get the latest release for your operating system here

Download the client

As of this writing, the client version software that shipped with the IBM PS/1 (RS 6.03.17); this version has produced the best results but it does require a small tweak which will be described below.

The software is archived here and the disk image is here.

Prepare the client

Instructions below are prototypical for Linux, but may vary for your preferred operating system.

% mount /path/to/client.img /mnt/floppy
% mkdir -p /tmp/prodigy/C/PRODIGY
% cp /mnt/floppy /tmp/prodigy/C/PRODIGY
% umount /mnt/floppy
% cat << EOF > /tmp/prodigy/dosbox.conf
 !!! config here - see below
EOF
% cat << EOF > /tmp/prodigy/phones.conf
5551212 localhost:25234
EOF
%

Dosbox Configuration

Dosbox configuration is beyond the scope of this document, but the default should work with a few tweaks:

[serial]
serial1       = modem baudrate:2400
phonebookfile = phones.txt

[autoexec]
mount C: /tmp/prodigy/C
C:
cd PRODIGY
PRODIGY.BAT

Run dosbox and prepare the client

% dosbox -conf /tmp/prodigy/dosbox.conf

When you first run the client software, step through the prompts, responding as follows:

• Which phone service do you have? TONE
• Please type your one-letter network symbol, then press [ENTER]. Q
• Type the Prodigy service/Users' Club phone number, then press [ENTER]. 5551212
• Now, simply close dosbox.

Make a small adjustment

Edit CONFIG.SM however you wish and remove the line that reads OBJECT:XTG00000.PG1; and save the file.

Run dosbox and connect

% dosbox -conf /tmp/prodigy/dosbox.conf

Now (and any time you re-run the client), you will be presented with the Prodigy logon screen.

Login with the default credentials created above (User ID AAAA11A and password SECRET). Upon logon you'll be prompted to complete enrollment and choose a new password. Subsequent logons will be with the new password.

Stopping and starting the service

After starting the service as described above, it should run in the foreground. It can be stopped with CTRL-C, and simply restarted with docker compose up. It will use the database that was already crated and populated.

Resetting the service

If at some point it is necessary to rebuild the service, it can be done by deleting the containers and volumes, then restarting them. Beware that this will delete all users and content you may have created.

docker compose down -v

Caveats

Neither DIA nor TCS protocols as implemented by the Reception System version targeted here provide a keepalive mechanism. If the server is run behind anything with aggressive TCP timeouts, such as a load balancer or NAT device, one may experience CM 4 errors in the Reception System.