Wednesday, November 25, 2015

Finding and reading in real decks to complete system load files


I ran a reload of the phases I had in a card tray that came with my 1130 system, which are the DMS R2 V12 reload that runs against a full V11 system to create a V12 disk. These phases, real card decks from my system, were reloaded atop the virtual disk cartridge that comes with the IBM 1130 simulator.

Brian Knittel had painstakingly recreated the virtual decks by assembling the decks from a source tape and listings, but this test would let me know if there were any discrepancies on disk from my phases. I did a reload of my decks and then a sector by sector compare with DCIP. I found that one of my decks, phase08, was not a complete set of cards. It was missing some cards and therefore was shorter in my deck than in a real system. That threw off the rest of the system.

I retrieved the phase 08 deck and reread it, ensuring I had a complete deck, then redid the reload of my phases. I will iteratively do this until I ensure the correctness of both my real deck files and the simulator virtual cartridge  Deck 08 was repaired but the work continues.

In a related project, I began reading in my DMS R2 V11 card files, where I should find all the phases that were not included in the V12 reload decks. There are 31 phases that were not changed in V12, thus not included in the reload. I obtained them all and completed a full set of load decks.These also contain the header card text I was looking to capture for my utility program, thus allowing me to produce accurate header cards.

Now I have several 'editions' of disk cartridges I can cross check to validate everything. I have the virtual cartridge from the 1130 simulator, the recreated phases I produce from a live disk cartridge with my utility programs turned into a virtual cartridge, and the real decks from my 1130 system turned into a virtual cartridge. To the extent that everything compares exactly, I can be confident we all have a true and faithful version of DMS2 V12 everywhere.

I grabbed the DUP portion of the R2 V11 deck in my trays and found that it had all the phases, so that it appears to be a complete initial load version, including RPG, FORTRAN, COBOL and the rest of the system.. All phases that aren't updated in V12 will come from here.

Turns out I have access to all the official header cards and all the official object decks. My utility program wasn't actually needed, although it will be a good cross check against any real cartridges I have and against the virtual cartridges from the site. The process of building and testing the utility reminded me (or taught me) a lot about the 1130 software stack.

Tuesday, November 24, 2015

System Load Deck utility working perfectly now


I have fixed the issue with formatting for the phases that have reload table entries and get apparently good results doing a reload of a couple of phases. However, comparing the disk sectors still shows that the contents of the sector don't match after the first 45 word card is punched.

It looks like I am picking up random data rather than the remaining content of the sector. The cause was the CARD0 library routine, which corrupted index register 1 during its execution. I saved the register around the library call and got an almost perfect match of the disk sectors between the original source version and the version reloaded by my program.

The problem is in the last word of the sector - I see an extraneous word on the new version. This is another of those nuance issues - where the way the last card of a system load deck should be produced. It has to do with how the SLET entries interpret the starting core address and number of words. I studied examples of decks for a while in order to lock in my spec for the utility program.

I ran a large batch of phases, about 90, through the reload process which finished normally. However, since the last word or so of each phase is not correct, the disk did not boot up and work properly. This is understandable. I am still working on getting what seems to be the last issue for my utility corrected

Once I had resolved those problems, I did a partial reload and had the system boot up fine. I am going to set up an initial load of a 'fresh' cartridge and then do a sector by sector comparison of the disk, checking for any discrepancies. That will be the acid test for the correctness of the decks built by my utility program.

I ran the large reload again and did a DCIP utility disk compare, which found zero discrepancies on the system phase sectors 8 to F5 where my reloaded modules sat. I had to make a quick fix to the utility to spit out the phases without the 9s separator cards, so I can use the large file to do a full initial load of the system.

That fix done, I created my all phases deck and did a reload to validate it all before moving to the new cartridge. Then I used the DCIP utility to initialize a fresh cartridge and ran an initial system load using my generated phases. It worked perfectly! DCIP did a disk compare and the sectors holding the system phases (0008 to 0139) are a perfect match - SLET, Reload Table and all the phases themselves.

I am very pleased and can now use this tool for a number of interesting things.

  1. Reload the simulator disk cartridge with the phase decks I read from my own card decks that came with the 1130 system. That might uncover discrepancies which would warrant investigation. 
  2. Create the decks as input to the UCART utility which will build a distribution cartridge that will mirror the way an 1130 owner would receive the DMS2 system from IBM.
  3. Recreate phase decks from the cartidges I received with my 1130, since they have all the compilers (RPG, COBOL and FORTRAN)

I also discovered the documentation that came with the DMS2 V12 decks - which shows that the phases which are missing in my collection were never shipped. They are phases that didn't change in V12, so they may be sitting in the DMS2 V11 decks. The distribution cartridge would not have been a V12 version, thus the decks I have are applied as a reload atop a V11 system.

My card trays have an R2 V11 deck, which on a quick investigation appears to have the first DUP phase (01) which was missing from my V12 deck. The documentation for V12 shows that DUP phase 01 did not change for the new version. Its header card has an earlier assembly date, while V12 is 11/06/73 for all the V12 phases.

Monday, November 23, 2015

Moving forward with system load deck and cartridge recreation

As I remain in the throes of a nasty cold, I don't have much energy to expend and mostly spend it in front of a PC instead of out with the 1130 system. I am trying to get better before my two weeks of travel beginning on Saturday, where I will be forcefully separated from the 1130 and related gear.


I continued with testing, working to get the object decks I punched from the utility program work properly with a system load initialization or reload for DMS2. From time to time I discover some nuance of how the decks are configured for system load, but mostly I am cleaning up subtle defects in my code.

As an example of nuances, I first determined that the output of a deck should start at its beginning address, with a specific pattern identifying where in the module the loader should update the code with the SLET entries which this module will call. However, some decks have these entries and thus are covered by the Reload Table. The module helps build the reload table entry with these beginning words. Other modules don't refer to any entries so I have two styles of beginning card to produce, either two or four words long.

At this point, phases that don't have a reload table entry are loading without error, but I have a minor flaw in the logic for the other module type. Also, when I do a word by word comparison of the original sector and my reloaded version, I see that something is awry in my 'stepping' logic for advancing through the words of the sector and produce load cards.

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


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.


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, 

Saturday, November 21, 2015

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.


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.

Friday, November 20, 2015

Utility to recreate phase decks from system cartridge working properly


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.


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. 

Thursday, November 19, 2015

Debugging my utility to produce a distribution cartridge and card decks


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.