Read in 1130 application deck, continued work on system load process

SYSTEM INIT DECK AND CARTRIDGE RECREATION

I worked on my utility program, painstakingly comparing the cards produced by my program to the cards from the assembly that created the original source disk cartridge. Still not going all the way through the system load process.

READING AND SAVING APP PROGRAM DECK FOR SOMEONE

A person donating an application program to the Computer History Museum wanted it read and an electronic copy sent to him, so I volunteered. It was exactly 1,866 cards which I fed through the Documation reader and converted to IBM 1130 simulator format, verifying each section after reading to eliminate any misread cards.

I have two Documation readers, model 600 and model 1000, but I have only made my hardware modification to the first one. This mod allows cards with the triangular 'cuts' on either the right or left sides to be read correctly. As built by Documation, the reader will get read checks on many cards with a triangle cut on the right side.

It seems that either my reader or my interface to the PC is balky, so that after running through 500 or so cards, it starts getting into wedged states that require me to reset. If I give the gear about 30 minutes to cool down, I can get it back to reading solidly for the next 500 or 600 cards. It wasn't too long until I had them all read in and was ready to do some deck processing.

The decks are split into separate decks, each one job - 21 subroutines, one list of error messages and two mainlines with sample data. Next up was to test these on the 1130 simulator to verify they all compile clean and perform reasonable things when run, after which I can send them to the donor.

All the decks compiled fine, but the two main programs made use of some subroutines that were not on the 1130 simulator system and not included in his deck. AMAX1, AMIN1, MOD, IDIF, RFRMT and the like. The first three should have come with a cartridge intended for a FORTRAN system, 

Debugging decks from my utility with the System Load process for DMS2

As I landed on Friday, I began sneezing and by the afternoon I was hammered by a strong cold. I only have this week before I head off to London and other places for a couple of weeks, but it is hard to do much work when I am so under the weather.

UTILITY TO BUILD SYSTEM LOAD DECKS AND CART

I discovered that the checksum logic includes a card sequence number in the calculation, something I hadn't included. That caused my decks to be rejected with checksum errors. I modified my code and ran again, until my decks passed muster for checksums.

The next problem I faced was some error that the system loader found in my cards, yielding the highly informative error E02 INVALID RECORD OR BLANK. Since I had no blanks in the deck, it was one of the 39 card images for the phase I was trying to reload. I successfully passed the checksums but now had something awry in my formatting,

As I corrected each issue, I found myself in more subtle difficulties, meaning I was getting very close to passing all the tests in the loader program. The larger question is whether an error free run would generate the exact clone of the data I used as the pattern. I kept at it. The last problem was an incorrect end card minus one, which appears to need to be one word long. There was a simple fix to my program to handle this.

Something is still not right with the last data card, which I will look into further tomorrow.

Utility to recreate phase decks from system cartridge working properly

UTILITY TO PRODUCE SYSTEM INIT DECK AND DISTRIBUTION CARTRIDGE

I continued testing the code as I flew home, getting it nearly ready to use. By the early afternoon I had a clean run through the first sector of the SLET - phases 01 to 98 - but found a bug in my code to skip the five device entries from 99 to 9D.  Once fixed, the utility appeared to punch out all the decks properly, with their header cards and all separated by the 9s cards the way that UCART punches the decks.

I am still missing the text for 31 of the header cards, since I didn't have those phases in my card trays. I will check a few other sources to see if I can capture the missing header cards. Since they are in straight hollerith code, it should be easy to snap a picture of a card to extract the text.

I need a quick small utility to split out the decks into separate files, so that they can be manipulated and used in an initial system load. My first major proof point of this will be to build a scratch disk cartridge on the 1130 simulator and use my deck of cards from the utility to load the disk. Then, I can compare them sector for sector with the cartridge I used as the input to my utility. They should match exactly.

If they do match, then I can run this on the real 1130 with my disk cartridges to capture the accurate object code shipped from IBM, The disk images we have online were recreated from source tapes and listings in a herculean effort by Brian Knittel but may have undiscovered differences due to typos or other transcription errors. This process will validate the total correctness of the simulator disk images.

The major purpose is to build the full system initialization object decks from my systems, including compilers like RPG, Fortran and Cobol, so that I can walk through the steps of system building and maintenance exactly as would have occurred decades ago with real machines and distribution cartridges.

READING APPLICATION PROGRAM FROM CARDS

The Computer History Museum is receiving a donation of an application program that handles garment designs and plots output on the 1627, but the donor would like a machine readable copy. The deck of cards was shipped to me so that I could read them with my documation card reader and convert them to the IBM 1130 simulator format. The deck is roughly one box of cards, about 2000 punched cards.

Since columns 73 to 80 are sequencing and identification, there are a maximum of 72 characters per card. This deck has just over 140KB of characters, but realistically probably closer to 60K since many cards are much shorter than 72 columns, with spaces taking up all the remaining columns. 

Debugging my utility to produce a distribution cartridge and card decks

DMS2 SYSTEM LOADER AND DISTRIBUTION RECREATION

Although I am away in Austin all this week at a conference, I have used my spare time to walk carefully through the programs I wrote that will build a set of cards decks that are as close to identical as possible to the decks punched out from the IBM Distribution Cartridge. I am fighting flaky punch behavior in the IBM 1130 simulator, but can get the remainder of the logic tested fully even with this problem.

Code development for system distribution utility

I am on a trip in Austin, Texas at the Supercomputing 2015 conference all this week, but will have plenty of open time to code, test and do other 1130 design work. More, in fact, than I have been able to do lately due to demands from my employer.

RECREATING SYSTEM LOAD DECK AND DISTRIBUTION CARTRIDGE

I have asked members of the IBM1130 google group whether they have a schema to recreate more of the header cards, or even a source for the 100+ sets of text that came with a system distribution. A reader of this blog had suggested that avenue.

Another complication I discovered is the Reload Table, kept in sector 6. The way this is built during the load depends on a feature of the assembled object deck which is lost in the contents on disk. The first four words of each phase are special to the loader. The second words is the 2s complement of the phase number, the third is the displacement into the file where the SLET entries sit, and the fourth is the number of SLET entries that must be processed.

If the phase is going to be placed in memory at location /1100 then the object deck emits four words starting at /10FE, which are the special entries described above, then the second card of the object deck has data starting at /1100. This means that the data in /1100 and /1101, used to point to the SLET entries inside the phase, are overwritten by the first instructions. What I will see on disk is the data from that second card, not the four words from the first card.

Fortunately, I can recreate the first card for those phases that contain SLET entries. The Reload Table, contained in sector 6 of the disk, consists of three word entries for any of the phases that contain SLET entries - not all do. The first word is the phase ID of the phase containing the SLET entries, the second word is the relative address of the SLET entries inside this phase and the third word is the count of SLET entries to be processed.

For any phase that I find in the Reload Table, I will create the first card in the desired format, otherwise I will make a first card with /0000 and 0 for the SLET location/count. That way, my decks will build the Reload Table exactly as it exists. I will also double check all the phases for which IBM1130.org has source, to see which have non-zero counts of SLET entries.

I am pleased to see that my method should work, having tested it against a few different disks, as it was able to recover the Reload Table information for RPG whose source is not available online. While I think my decks of RPG and COBOL are complete, it is good to know I will be able to handle any system distribution.

I continued to code up the utility programs to recreate the distribution media while in Austin. Test, code more, test more - what a way to while away the idle time between sessions and meetings.

Building utility to recreate the system load deck and build a distribution cartridge image

RECREATING DISTRIBUTION DECKS

I continued coding the routines that will run through a system cartridge, using the SLET table to find and punch every system file as a card deck - very much like was produced by booting the distribution cartridge from IBM. That cartridge had a program, UCART, to punch all the card images, each phase or file separated by a card with all 9 characters.

My program will read in the phases from the system area and produce a card deck that is equivalent to the official DMS V2 R12 version. It is not identical for a couple of reasons. First, the header card in the IBM decks, which come out from UCART, contains text information about the module which is thrown away as the phase is loaded to a disk cartridge. Second, the object decks are output from the assembly, skipping areas that were coded as BSS (block of reserved locations) and starting a new card when an ORG card was present, while I will produce a tightly packed object module with every card but the last full.

Since the header text is gone, I can try to copy the headers of as many decks as I can find, either those phases for which I have a deck, or decks at other 1130 installations. These are human readable and not directly related to either the phase name or even the heading on the assembly, for those where I have source code. For example, phase 002 which is Job Control 2, with a sequence code starting J0212001 in columns 73-80, has a header card that reads:
"    1 SJB 02 11/06/73 DUP-CTRL RECORD PROCESSOR                    V2M12 J0212001"

One can guess that it contains the data of last modification, the initials of the programmer changing it, but also has a code '02' whose purpose is unknown. The heading entries in the source deck are of the form "DCTL -DUP CONTROL - COMMA " with various names after the second hyphen. Nothing in the source indicates the date of last assembly, nor could you create "DUP-CTRL RECORD PROCESSOR" from "DCTL -DUP CONTROL".

What I am confident about is that the results on a disk cartridge, in the system area, will be identical word for word between the cartridge I use as the reference source and any cartridge built using my decks. In that way, they will produce identical results on disk even though a card by card comparison of the IBM version and my output will differ.

The SLET table takes a couple of thousand words in core, the largest phase takes almost 5000 words when read in, and a table with the header text I want punched will take over 7000 words. The total, 14K, will fit on a 32K word machine but my physical 1130 where I will run the programs is only a 16K configuration. That means I have to get smart and optimize the program to conserve core - but I will do that in a second pass after I get the basic 'in memory' version functioning properly.

So far, I have testing and verified functions to read in the SLET table and to read each phase from the system area based on the SLET entry. While I am on my trip to Austin for the next six days, I will finish coding and testing the rest, then cutting it down to fit in a 16K machine. It is possible to skinny it all the way down so that it could fit in a 4K machine, but at the present time I don't see the need for that.

1053 carrier return cord attached; working on DMS2 distribution deck recreation

1053 CONSOLE PRINTER RESTORATION

Refastening the carrier return cord - the cord that pulls the carrier to the right during space and tab under pressure from the mainspring and which in turn winds the mainspring during carrier return operation - is a huge pain. There are two counter-winding pulleys on a common shaft, one taking up string during rightward movement and the other taking up string during return, with that shaft connected to the mainspring. The cord has to fit over five small pulleys in its run.

To be precise, there are two separate cords. one winds up on the pulley during rightward carrier movement, goes around two smaller pulleys and hooks to the carrier on its right side. The other cord is attached to the pulley that winds up during carrier return operations, goes over three intermediate pulleys and then hooks to the left side of the carrier. One of the small pulleys for the first cord is also spring loaded, in order to establish the right tension but buffer the cord from minor stresses during operation.

The return side cord is wound on its pulley, routed over three pulleys and the carrier pulled rightward to keep it taut. Then, the forward side cord is wound on its pulley, routed over two pulleys including the one with spring pressure, then hooked to the carrier. To get the right tension involves a gross adjustment and a fine adjustment.

The gross adjustment comes from loosening two hard to get to screws in the rear return side pulley where the return cord winds, rotating that pulley on its common axis relative to the rightward cords winding pulley. This is quite hard to do, as the two cords have to be on all their pulleys and in the right grooves of the two winding pulleys, while I hold one and try to rotate the other relative to it.

When the gross adjustment gets the cord to be free of slack when the small spring loaded pulley is partway depressed, then the fine adjustment is done on that spring loaded pulley to set it in the middle of its travel range.

I spent 30 minutes fighting everything and have the gross adjustment almost were it needs to be, but get frustrated by all the spots where cords can pop off pulleys or jump over grooves as I manipulate things.

When I took a rest break and returned, I was finally able to get it back together. The gross adjustment is decent, but I don't have quite enough tension on the spring loaded pulley. For now, it will be good enough.

The next area I need to look at carefully is the interaction between the carrier and the margin mechanisms. I have had the carrier 'jump' over the left margin during some return operations, which is definitely not acceptable, which implies either a bent part or some alignment that needs changing.

CREATING DMS2 DISTRIBUTION DECKS

I now suspect that the file format of the tray images I found on the internet are big-endian rather than little-endian, which foils the display utilities from the IBM1130.org simulator. Meanwhile, I continued testing and developing more of the code that will create the object decks for a System Load of DMS2.

The code that reads a system file into a buffer, given the SLET entry for the file, is working properly. The next bit of code is the subroutine which will punch that buffer as card images in the proper format for use during the system loader process, putting out the right header and trailer cards as well. When debugged, it can be combined in a mainline routine that reads in the SLET and walks through the entries to punch out the decks for them.