Free Web Hosting by Netfirms
Web Hosting by Netfirms | Free Domain Names by Netfirms

1301 Operating

 

Back to ICT Putney

Running a job:

This is totally from memory - and bound to be wrong... but: (since writing that (Sept 2002), I've received reminders from Dave Wilgoss (thanks Dave), and his suggestions are in green)....

I am sure that you are thinking about the 1300/01. The programming of the 1300, as I remember it, (not that I did any) was based on the commands beginning with 37, 38 at the start of the word. I/O and start called the bootstrap program to read a card etc.

bullet

Check the Run Request form - and ensure Printer/Card Punch are "started"

bullet

Load Tapes as designated - Scratch Work Tapes

bullet

Load cards into right hopper (did we have to add some "Bootstrap" cards to the front of whatever the Programmer provided??) - hit Start - card reader motor and picker knives start

bullet

We may have to set some external indicators 20 to 29?? which identified "options" that the program had to test for and branch respectively

bullet

On console:
bullet

Turn main switch one click to the left

bullet

Hit Initial Orders button - which set up "read 200 words from the first reserved band on the drum into word 200 and branch to 200" instructions in the Control Registers

bullet

Turn main switch back right to central position

bullet

Hit Start button

bullet

Cards would start reading and the Initial Orders program from the drum would load the instructions on the cards into memory. The card reader used to read cards column by column - 6 at a time.

bullet

If it ran OK - there would be a flurry of activity - maybe card reading and/or punching and printing and an "expected" Halt instruction - otherwise...

bullet

There was a Gain Control at bottom right of the Console, that allowed us to detect if the program appeared to be looping - not too sophisticated!!

bullet

The programs were self-modifying and de-modifying - so the usual "crash" was caused by programs modifying their addresses - out of range - and we'd then log the contents of all Registers (A,B,C and Control) and print out Core Memory - which entailed:
bullet

At the end of each operation that got past the “E” card the operator had to dump the first 200 words of IAS onto the drum. Then call down the print program from the drum to print out the IAS contents, which automatically called down the first 200 words from the drum. You will recall that if the operator forgot to dump the first 200 words to the drum, the programmer received a printout of the print program. Operator Error!

bullet

Encode a Print of IAS (Memory - Immediate Access Store) as directed by the programmer - e.g. 0 to 1000 words

bullet

Tear off the Memory Dump, re-band the program cards - replace Operating instructions and Run-Log - End

General memories:

bullet

I can remember on P3/1 splitting the tasks as follows - one operator selected the next job, and loaded cards, and checked peripherals

bullet

The other operated the Console and initiated the Memory Dumps, and completed the Run-Log

bullet

The "enjoyment" came from:
bullet

For the Console Operator:
bullet

Getting the Peripheral man running round like a blue-arsed fly:
bullet

as soon as he'd got cards in the reader, the Console guy would hit the buttons and try to catch his fingers with the picker-knives (they wouldn't have touched - but it felt as though they did)

bullet

Then logging the crash details and initiating a Memory Dump before cards etc could be re-banded - the Peripheral guy having to off-line the printer, throw 2 or 3 pages - on-line the printer again - go round the back - fold up (it invariably folded incorrectly) the print-out and package everything, and start all over again with the next job - before the Machine Log had been entered, showing details of the Test.

bullet

For the Peripheral Operator:
bullet

Getting the Console Operator to re-key - by:
bullet

Appearing to have the cards in the reader - but actually holding them slightly off the reader bed - MisFeed! Then just drop them and proceed to other tasks

bullet

Leaving the Printer Off-Line after a Memory Dump - so that the next Memory Dump  crashes

bullet

Operations more complicated on a 6 tape-deck machine like P3/2 where certain physical decks may from time to time be "iffy' like they "threw loops" - so they couldn't be used for any frantic popping up and down the tape - so we had to recognise which logical tape assignments the Test required and allocate/load tapes accordingly (i.e. each tape deck was capable of being assigned its Tape Deck Number - they were not fixed).

bullet

Three operators were needed sometimes - where the Job Testing load was big and time was critical - Console Man, Job Selector/Peripheral Man and Tape Man.

bullet

Job Selector would shout out what tapes were required - e.g. Scratch Tapes on 4 and 5 and Supplied Tapes A on 1, B on 2, C on 3

bullet

Work Tapes would be loaded on 4 and 5 first - and Scratched - this required co-ordination between Console and Tape Men - because Console Man had to initiate the "Scratching" of each tape - and sometimes an input tape (which the programmer had maybe spent hours creating - got accidentally scratched) - this ideally didn't happen because "input tapes" would be loaded without a "write-ring" - however - a common failure was - for a previous job to have ended successfully, and to have created an Output tape - on Deck 4 say - where a Scratch tape with a write-ring would have been loaded. It would have been printed - so the programmer could see that it was OK - BUT - if it was left on deck 4 too long - it may get scratched by Console Man when he's initiating the next job, and the Programmer of the earlier job need that tape to be used as input to another program - hence claims for "operator Error" - and "no-charge".

bullet

Programmers getting their timing wrong, and not getting back to the "next 6 columns" coming in from the card reader - causing the card to "misfeed" into a separate stacker. These were particularly annoying since they required the console operator to reset registers etc.. and the peripheral man - to reload the cards from misfeed and regular stackers (there was always a card or two following the misfeed, that had to be re-sequenced and put back into the feed hopper.

bullet

Card Reader failures which required engineers to load their diagnostic programs in through the "read brushes" on the card punch.

bullet

The printer caused lots of programmer problems too - they would sometimes "lift all sprags" - which set the paper throwing, and again get their timing wrong, come back to lower a sprag, but by then the printer mechanism was going too fast and the lowered sprag got broken/snapped off. Another problem was trying to print all letters/numbers in one revolution of the barrel - this was usual - but here I mean printing the whole alphabet etc... in one print position. This caused the hammers to fire too quickly and fuses blew.

Back to ICT Putney

_____________________________________________________________________________

Links in this site

Shepperton Bing Crosby Triffids Olney 519 Reproducer Newman Street Natsopa Shedland MRPE-DRPE Vibeke Maltravers Melton 1900 Programming Pergammon Letts Howell & Hall Farquhar Arrow Electric Tom Curley Boulting George Pitcher May Flower John Flower Angela Flower Joan Collins Navarone Moor Hall P3/1 ICT 1500 Initial Orders Scicon Bell & Howell British Leyland Charles Letts Philipp Bros The Times ICT/ICL 1900 Bob Hope Charles Little Arnold Keppel Bob Tester 609 Calculator 412 Tabulator P3/2 RCA 301 FP2 Barry McGinn Aramco Chicago Bridge & Iron Gaudern

__________________________________________________________________

 Visit my other sites....

Go to:  Home Web-Site | Lived | Schooled | Family | Pools | Computers | OddsnSods | Photos web-site | POWWEB-1 | POWWEB-2  | Christianz Interiors

Last update - September 9th, 2009 - email to djmikecurley@gmail.com