Working on a way to run DMS-2 on an 1130 without a working card reader and line printer

CHALLENGE FOR SOME OWNERS OF IBM 1130 SYSTEMS

The IBM 1130 was developed by IBM in the era of batch processing. Input was punched onto cards, work was processed serially and the results were output on line printers. Many users might share a machine by submitting their decks of cards. The decks were stacked in the reader, processed one by one and the output pages were returned to the user later. 

There were some alternatives for input and output, but the bulk of processing involved card decks and printed output. A keyboard, console printer (typewriter), switches, paper tape reader/punch, plotters, disk drives and other devices offered those alternatives. 

The controlling software for the IBM 1130 was Disk Monitor System (DMS). The latest version of the software was release 2, with most people referring to it as DMS 2. Enhancements and fixes to bugs were rolled out in incremental versions. The last official release was DMS V2 R12 although some bug fixes could be applied if you wanted a 'V2 R13'. 

Most IBM 1130 systems came with one internal disk drive which used 2315 cartridges holding about 500K words. Additional drives could be attached (IBM 2310 or 2311) for larger installations. DMS 2 was installed on one or more cartridges. 

To start the system, a boot card was placed in a card reader and the Prog Load button on the console loaded that in memory and began execution. That card's program would fetch in DMS 2 from a disk drive and turn over control to the monitor. The first thing that DMS 2 would do as it started was to print a page on the line printer, pretending that it had read a control card (// JOB) from a card reader. 

Decks started with a // JOB card to delineate a new element of work, often a new user. The deck is read by DMS 2 to find control cards - these can start compilers like Fortran or utility programs like DUP (Disk Utility Program) or user programs (// XEQ). The programs such as a compiler will read cards to accomplish its part of the job, then return to the monitor to look for the next control card. One might call a compiler (// RPG) then run the program (// XEQ). When the monitor finds the next // JOB card, it begins the next job. 

In general practice, to load DMS 2 from the disk requires a boot card (cold start card) in a working card reader. DMS 2 won't fully start without a working line printer to display that first // JOB card. It tries to read cards from the reader in order to find control cards. If an installation does not have a working line printer and a working card reader, nothing can be accomplished. DMS 2 waits at a special location x002A with a code in the accumulator register (ACC) showing which device is not ready or not working properly. 

While you could toggle in some code to memory to act as the cold start card, once DMS 2 is loaded from the disk drive, it will wait for the missing line printer. If that barrier were overcome, it would then wait for the missing card reader. This makes demonstrating an IBM 1130 in a museum challenging unless you have the printer, card reader, and disk drive working. 

DMS 2 DID NOT PROVIDE DEVICE INDEPENDENCE

Device independence is a common design objective with operating systems to provide a common interface that allows a program, without modification, to use different device types. Within reason - you can't expect to read data from a plotter for example - but modern software might allow you to read from a card reader, a tape drive, a disk drive, a keyboard, as well as multiple types of card readers. 

This was not a general capability of DMS 2, with only a primitive degree of independence provided. Printed output could be directed to the 1132 or 1403 line printers, or to the console printer (Selectric based typewriter). However, the program had to format the output in the character code of the specific printer being used, so that it had to be modified if you switched between printer types. 

For input of decks, the 1130 could use the 1442 or 2501 card readers, the keyboard on the 1130, or the 1134 paper tape reader. The character code of the paper tape reader differed from the Hollerith code used with the first three devices. 

DMS 2 was generated for an installation, tailored to the devices being attached to the machine. As part of that tailoring, DMS 2 assigned one card reader and one line printer as the principle input device and the principle output device. This is the primitive level of device independence offered. 

When reading control cards, DMS 2 would refer to the principle input device rather than the specific 1442 or 2501 driver. Similarly, when printing the // JOB card and other monitor data it would use the principle output device instead of the specific 1403 or 1132 device drivers. 

Installations could have multiple types of readers and/or line printers. DMS 2 would always use the one assigned as the principle device, but user programs could read/write to the device of their choice which made use of the specific device driver. 

CONSOLE PRINTER AND KEYBOARD AS ALTERNATE PRINCIPLE DEVICES

DMS 2 did allow the console printer and the keyboard to be used as the principle devices by reading specific control cards. The // CPRNT control card would switch the principle output device from a line printer to the typewriter. The // JOB card and other monitor output is typed on the console printer. This continues until a // CEND card is read which changes the principle output back to the assigned line printer. 

The change of the principle output device was written back to disk, so that any time you booted DMS 2 after a // CPRNT had been executed, the monitor output would be typed rather than sent to a line printer. This could resolve the problem where DMS 2 hangs at startup due to a missing line printer. 

DMS 2 could switch the primary input device to the keyboard when it executes a // TYP control card. All subsequent monitor cards are read from the principle input device, e.g. from the keyboard. This is NOT written back to disk however so upon a reboot DMS 2 would again hang waiting for a missing card reader. 

Using the console printer and keyboard is very cumbersome and impractical for meaningful decks to be entered. DMS 2 and its programs used fixed columns for card fields, unlike the free form input of most modern systems. An Assembler input card      LOOPX LDD I *-4 must match the column requirements of the assembler. 

• Columns 1 to 20 are ignored  
• Columns 21 to 25 are the name field of the statement, with any name left justified in the field
• Column 26 (and 31 and 34) are ignored
• Columns 27 to 30 are used to enter an operation code or assembler directive name, left justified
• Column 32 is used to mark a long format (doubleword) instruction using L or indirect using I
• Column 33 is used to select one of three index registers entering 1, 2 or 3
• Columns 35 to 71 hold the operand, left justified
• Columns 72 to 80 hold card sequence numbers, used to sort a card deck into order

If using the keyboard, the user would need to space precisely to column 21, 27, 32, 33, and 35 in order to type in the left justified nonblank input. There is no way to go back to earlier 'cards' to make changes, only some primitive line editing for the current 'card'. 

Perniciously, it takes a working card reader to read in a // TYP in order to switch to the keyboard. Since the change to keyboard is not recorded on disk, each boot of DMS 2 returns to the card reader as the principle input device.

STRATEGY TO CORRECT THIS

I think the most straightforward way is to cold start DMS 2, with it having previously processed the // CPRNT card making the typewriter our principle output device. It will type out the initial job card information and then stop at x002A with a card reader not ready condition.

I will work out how to enter a // TYP card in the buffer and a way to branch into the card reader to make it return to the monitor claiming a successful read of a card. The monitor will process the // TYP, changing the principle input, leading to the Keyboard Select lamp lighting on the console next.

I did a lot of source code examination of the monitor logic that reads the control cards as well as the device driver for the card reader. It isn't enough to zap the disk image after a // TYP because the execution of that command loaded a different device driver and changed quite a few words in core. That would mean I would have to update a substantial number of memory words to place the correct driver and control words in core. It is easier to let the monitor handle the work by feeding it a // TYP card.

METHOD TESTED ON IBM 1130 SIMULATOR

The card buffer for the monitor control records sits at 0x0faf with the first word containing the word count (0x0050 or 80 columns) for the read. The data in that buffer is read as Hollerith characters but the card reader routine will convert them to EBCDIC characters before they are processed as monitor records. 

This means the desired card - // TYP - reads in as 3000 3000 0000 2400 2020 4040 0000 0000 . . . 0000 but when it is converted and packed two characters per word, it becomes 6161 40E3 E8D7 4040 4040. . . 4040 instead. I have to load the buffer with the Hollerith values, then branch back as if the card read device driver finished the read and now wants to convert it. 

I was doing something wrong because the conversion is not completing successfully. I see the card columns converted from Hollerith to EBCDIC but they are not packed two characters per word. I thought I must be branching to the wrong place. 

After tracing the execution a bit, I realized that it there was some flag that wasn't right so it was trying to read another card. If the flag had been correct it would have branched to the routine to pack the characters two per word and then process the command. I set the IAR to that routine and started execution. It worked!

PROCEDURE ON A SPECIFIC DISK

On the disk I had loaded with DMS 2 and previously configured for printing on the typewriter, the monitor control record processing code sat starting at x04FE which determines the locations to use in the procedure. It is likely that other disks will use the same address if they were loaded with the same version of DMS 2 but I would always test to be certain.

Boot DMS 2 and verify it is at 0x002A with 0x3000 in the ACC register - wait for card reader not ready. 

The card buffer sits at 0x0fb0 to 0x0fff. The first step is to clear that buffer to all spaces - 0x0000 then enter the Hollerith code of our // TYP card. Starting at 0x0fb0 we enter:

• 3000
• 3000
• 0000
• 2400
• 2020
• 4040

The IAR is set to 320, the address where the card reader routine will execute to return after it has successfully read a card into the buffer. Press Prog Start and the machine waits again at 0x002A with 0x3000 in the ACC. Set the IAR to 5C6 and press Prog Start. The Keyboard Select lamp will light on the console indicating this has worked, plus the // TYP card will be typed out on the console printer. 

LIMITATIONS OF THIS WORKAROUND

This process will allow DMS 2 to be run and some work can be performed using the console printer and keyboard as the principle output and principle input devices. However, many programs will use the actual device driver for line printers rather than go through the principal output device. This will cause them to stall at x002A with a printer not ready condition. 

For example, I was able to invoke DUP with a // DUP card and that program did read its input from the keyboard. However, when I invoked the DUP command *dumplet to list the contents of the disk directory, the output went to the 1132 line printer and not the typewriter.