9 Track Tape Drive passes self tests and loads tape; Continuing post processing of 1130 card decks; awaiting cards to read for someone else

 DIGITAL TSZ-07 DRIVE POWER UP AND INITIAL TESTING

I gave up on hunting down schematics or reverse engineering the power supply. I went with the simpler option of energizing it with AC while the outputs were disconnected from the tape logic boards. After that I reinstalled everything and brought up the tape drive.

I did take some time prior to power-up to use IPA to clean the heads, rollers and the inside of the transport area. Everything looked clean, free of excessive wear, thus ready to use. It runs self-diagnostics and reports what portions of the machine might have failed. In my case it came up with a clean pass of the tests. 

Drive passed self tests and is loading a tape

I then grabbed a blank 9 track tape, stuck it in the drive, and hit Load. The tape loaded, it sensed the density of the tape (6250 BPI) and correctly reported that I had a write ring in the tape. Unload also worked properly. Next up, I need to cable this to the SCSI bus on my P390 system and see whether the SCSI board can talk to the drive. 

Tape at load point and apparently ready to acces

POST PROCESSING OF A FEW MORE FILES

I spent hours organizing, splitting up and documenting all the files for the Keyword in Context (KWIC) application. This set of programs creates an index by keyword of a list of books or documents allowing someone to read the listing to find all documents that contain a given keyword. Kind of a 1960s version of Google. 

I used my program to test the sequence number fields, which proved to me that we had clean decks without missing cards or duplicates. I was able to compile all the programs, create the empty disk files, and prepared to run the sample input. I don't have any documentation on the format of data cards nor about how to operate the program, thus I had to feel my way through this.

The complete deck from IBM PID apparently had dependencies on some other package, since I couldn't execute the resulting application due to missing subroutines. This is something you don't learn until execution time for most 1130 programs, because of the way that the system works.

Compiling a program, say with FORTRAN, produces an object module that contains within it a list of external references such as subroutines it needs to call. The relocatable object module is what is stored on the disk in the User Area (UA) most times. 

When you issue // XEQ for the main program name, the Core Load Builder (CLB) component starts up and does what the 360 operating systems would call a link-edit. It links together the program with all its referenced external objects, adjusts addresses to the absolute location in core where the software will be placed, and then passes that core image (CI) format module to the loader for execution. 

It is possible to have the CLB convert an object module into CI format in advance, using the Disk Utility Program to force that link-edit action, but the resulting stored program is much larger and locked to specific core locations. If ten object modules each reference the same subroutines, only one copy of the subroutine exists on disk if they object modules are relocatable, but if they are converted to CI then there are ten copies of the subroutine taking up disk space. 

It was when the CLB got involved that I first discovered that I needed missing subroutines NCOMP and PACK. Later phases of the application also needed the subroutine UNPAC. These were not supplied with KWIC but I dug through all my archived card decks and found these in the Complex Subroutines set of cards. 

Once I loaded these subroutines onto the disk, the CLB completed and the KWIC application started up. I found that it asks a series of questions on the console typewriter/keyboard to guide execution, such as whether to preserve existing content in the keyword or book files. Once I figured out this referred to groups of data cards in the sample execution deck. I guided the application to read the keywords and the book data. There is a format card which describes which columns on the data cards refer to titles, authors, etc so that has to be loaded. 

I did get it to read all the cards and process the index, then it asked me if I wanted to print listings of the index and a report. I collected both the console typewriter and line printer output files and saved them along with the other files from PID. To wrap this up, I wrote a document describing the files and the basics of this application. 

There was another PID filed called KWIC Generator, which looked similar but smaller than the KWIC application. I began the process of verifying this on the IBM 1130 Simulator as well, getting the program to compile successfully, but this program needed to be stored in CI mode because it had to refer to a temporary disk file that was bound to the program.

Alas, there is a flaw somewhere in the simulator. Anytime you ask DUP to run CLB, it looks forever on the *STORECI command. CLB works fine as part of an XEQ but not under DUP. As a result I couldn't finish my testing of the KWIC Generator application. I do need to attack this problem with the simulator as there will be many other cases where I will need STORECI to work properly.

CONTACTED TO READ OLD SOFTWARE DECKS FOR SOMEONE ELSE

I received an email through some friends seeking some way to read a deck of punched cards for someone. While a grad student, he had written some software in Fortran that he wanted to port to modern systems today. Perfect timing, as soon as he ships them down to me here I will archive the contents and send everything back to him. As a bonus he may have some mainframe simulation software package on cards that I can also archive. Not sure if it is GPSS or CSMP, but both are modeling/simulation packages which were distributed by IBM PID (Program Information and Distribution) department.